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Abstract 

Monads are now an everyday tool in functional programming for 
abstracting and delimiting effects. The link between monads and 
effect systems is well-known, but in their typical use, monads pro- 
vide a much more coarse-grained view of effects. Effect systems 
capture fine-grained information about the effects, but monads pro- 
vide only a binary view: effectful or pure. 

Recent theoretical work has unified fine-grained effect systems 
with monads using a monad-like structure indexed by a monoid of 
effect annotations (called parametric effect monads). This aligns 
the power of monads with the power of effect systems. 

This paper leverages recent advances in Haskell's type system 
(as provided by GHC) to embed this approach in Haskell, providing 
user-programmable effect systems. We explore a number of practi- 
cal examples that make Haskell even better and safer for effectful 
programming. Along the way, we relate the examples to other con- 
cepts, such as Haskell's implicit parameters and coeffects. 

Categories and Subject Descriptors D.3.2 [Programming Lan- 
guages]: Applicative (functional) languages; F.3.3 [Logics and 
Meanings of Programs]: Type Structure 

Keywords effect systems; parametric effect monads; type systems 

1. Introduction 

Side effects are an essential part of programming. There are many 
reasoning and programming techniques for working with them. 
Two well-known approaches in functional programming are effect 
systems, for analysis, and monads, for encapsulating and delimiting 
effects. Monads have a number of benefits. They provide a simple 
programming abstraction, or a design pattern, for encapsulating 
functionality. They also delimit the scope of effects, showing which 
parts of a program are pure and which parts are impure. However, 
compared to effect systems, monads have two limitations. 

1). Granularity The information provided by monadic typing is 
limited. We can look at the type of an expression and see, for 
example, that it has state effects if it uses the ST monad, but we no 
nothing more about the effects from the type; the analysis provided 
by standard monadic typing provides only binary information. 

In contrast, effect systems annotate computations with finer- 
grained information. For example, stateful computations can be 
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annotated with sets of triples of memory locations, types, and effect 
markers a £ {update, read, write}. This provides information on 
how state is affected, without requiring the code to be examined. 

One solution for improving granularity is to define a type class 
for every effectful operation, with a type class constraint over a 
polymorphic monadic type [15|. However, this restricts an effect 
analysis to sets with union and ordering by subsets. 

2). Compositionality. Monads do not compose well. In Haskell, 
we often have to refactor monadic code or add additional book- 
keeping (for example, insert lifting when using monad transform- 
ers) to compose different notions of effect. In contrast, effect sys- 
tems which track information about different notions of effect can 
be more easily composed. 

The recent notion of parametric effect monads 1 12 1 (also called in- 
dexed monads 1 1 9 ] ) provides a solution to granularity, and a partial 
solution to compositionality. Parametric effect monads amplify the 
monadic approach with effect indices (annotations) which describe 
in more detail the effects of a computation. This effect informa- 
tion has the structure of a monoid (F, • , /), where / is the annota- 
tion of pure computations and • composes effect information. The 
monoidal structure adorns the standard monad structure, leading to 
the operations of a monad having the types: 

return :: a — > Mi a 

(»=) :: M F a -J- (a -> M a b) -> M F . G b 

The indexed data type MfA may be defined in terms of F, giving a 
semantic, value-level counterpart to the effect information. This ap- 
proach thus unifies monads with effect systems. This paper makes 
the following contributions: 

• We encode parametric effect monads in Haskell, using them to 
embed effect systems (Section [2}. This provides a general sys- 
tem for high-granularity effect information and better composi- 
tionality for some examples (Sections |5|6} . This embedding is 
shallow, we do not require any macros or custom syntax. 

• We leverage recent additions to the Haskell type system to 
make it possible (and practical) to track fine-grained informa- 
tion about effects in the type system, for example using type- 
level sets (Section (3). In particular, we use type families (5), 
constraint kinds 13 201, GADTs 1221 . data kinds and kind poly- 
morphism 1251 . and closed type families Q. 

• A number of practical examples are provided, including effect 
systems arising from reader, writer, and state monads (Sec- 
tions |5|6) , and for analysing and verifying program proper- 
ties including computational complexity bounds and complete- 
ness of data access patterns (Section[5]l. We provide a Haskell- 
friendly explanation of recent theoretical work and show how 
to use it to improve programming practice. 

• We discuss the dual situation of coeffects and comonads (Sec- 
tion [8]( and the connection of effect and coeffect systems to 
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Haskell's implicit parameters. Implicit parameters can be seen 
as an existing coeffect system in Haskell. 

The code of this paper is available via Hackage (cabal install 
ixmonad) or at http : / /github . com/dorchard/ef f ect-monad 
In the rest of this section we look at two examples that demon- 
strate the problems with the current state-of-the-art Haskell pro- 
gramming. The rest of the paper shows that we can do better. 

Problem 1 Consider programming stream processors. We define 
two stateful operations, writeS for writing to an output stream 
(modelled as a list) and incC for counting these writes: 

writeS :: (Monad m) => [a] — > StateT [a] m () 
incC :: (Monad m, Num s) =>■ StateT s m () 

We have planned ahead by using the state monad transformer to 
allow composing states. Thus, an operation that both writes to the 
output stream and increments the counter can be defined using 

lift :: (MonadTrans t, Monad m) =>■ m a — > t m a: 

write :: (Monad m) => [a] — > StateT [a] (StateT Int m) () 
write x = do {writeS x; lift $ incC} 

In combining the two states, an arbitrary choice is made of which 
one to lift (the counter state). The following example program 

hellow — do {write "hello"; write " "; write "world" } 

can be "run" by providing two initial states (in the correct order): 

runStateT (runStateT hellow "") 0 

evaluating to (((), "hello world"), 3). The type of hellow indi- 
cates in which order to supply the initial state arguments and which 
operations to lift in any future reuses of the state. 

Consider writing another function which counts the number of 
times hellow is run. We reuse incC, lifting it to increment an 
additional state: 

hellowC = do { hellow; lift $ lift % incC } 

Now there are two Int states, so the types provide less guidance on 
the order to apply arguments. We also see that, for every new state, 
we have to add more and more lift operations, chained together. 

The parametric effect monad for state (Section|6j allows defini- 
tions of incC and writeS that have precise effect descriptions in 
their types, written: 

incC :: State '["count" \-¥ Int :! RW] () 
writeS :: [a] -» State '["out" [a] :! RW] () 

meaning that incC has a read- write effect on a variable "count" 
and writeS has a read- write effect on a variable " out " . The two 
can then be composed, using the usual do-notation, as: 

write :: [a] -> State '["count" Int :! RW, 

"out" :->[a]:lRW]Q 
write x = do { writeS x; incC} 

whose effect information is the union of the effects for writeS and 
incC. Note that we didn't need to use a lift operation, and we now 
also have precise effect information at the type level. 

An alternate solution to granularity is to define a type class for 
each effectful operation parameterised by a result monad type, e.g., 

class Monad m =>• Output a m where writeS :: [a] — > m () 
class Monad m => Counting m where incC :: m () 

Suitable instances can be given using monad transformers. This ap- 
proach provides an effect system via type class constraints, but re- 
stricts the effect annotations to sets with union (conjunction of con- 
straints) and ordering of effects by subsets. In this paper, we embed 
a more general effect system, parameterised by a monoid of effects 
with a preorder, and show examples leveraging this generality. 



class Effect (m :: k — >*—>*) where 

type Unit m :: k 

type Plus m (f :: k) (g :: k) :: k 

type Inv m (f :: k) (g :: k) :: Constraint 
type Inv m f g = () 

return :: a — > rn ( Unit m) a 
(»=) :: Inv m f g =>■ 

mfa~^(a^mgb)~^m (Plus m f g) b 

class Subeffect (m :: k —>*—>*) f g where 
sub :: m / a — > m g a 



Figure 1. Parametric effect monad and subeffecting classes 

Problem 2 Consider writing a DSL for parallel programming. We 
want to include the ability to use state, so the underlying imple- 
mentation uses the state monad everywhere to capture stateful op- 
erations. However, we want to statically ensure that a parallel map- 
ping function on lists parMap is only applied to functions with, at 
most, read-only state effects. The standard monadic approach does 
not provide any guidance, so we have to resort to other encodings. 

With the embedded effect system approach of this paper we can 
write the following definition for parMap: 

parMap :: ( Writes /~'[]) => 

(a -> State f b) -> [a] -> State f [b] 
parMap k [] — sub (return []) 

parMap k (x : xs) = do (y, ys) <— (k x) 'par 1 (parMap k xs) 
return (y : ys) 

The predicate Writes /~'[] on effect information constrains the 
computation to be free from write effects. The par combinator 
provides the parallel behaviour. 

2. Parametric effect monads 

While monads are defined over parametric types of kind m::* — > *, 
parametric effect monads are defined over types of kind m : : k — > 
* — > * with an additional parameter of some kind k of effect types. 
We define parametric effect monads by replacing the usual Monad 
type class with the Effect class, which has the same operations, but 
with the effect-parameterisation described in the introduction. 

Figure [T] gives the Haskell definition which uses type families, 
polymorphic kinds, and constraint kinds. Plus m declares a binary 
type family for composing effect annotations (of kind k) when 
sequentially composing computations with bind Unit m is 

a nullary type family computing the 'unit' annotation for the trivial 
(or pure) effect, arising from return. The idea is that Plus m and 
Unit m form a monoid which is shown by the parametric effect 
monad axioms (see below). 

The Inv family is a constraint family [ 3 , 20] (i.e., constraint- 
kinded type family) which can be used to restrict effect parameters 
in instances of Effect. The default is the empty constraint. 

do-notation Haskell's do notation provides convenient syntac- 
tic sugar over the operations of a monad, resembling the imper- 
ative programming approach of sequencing statements. By using 
the rebindable syntax extension of GHC, we can reuse the stan- 
dard monadic do-notation for programming with parametric effect 
monads in Haskell. This is why we have chosen to use the standard 
names for the return and operations here. 

Axioms The axioms, or laws, of a parametric effect monad have 
exactly the same syntactic shape as those of monads, but with the 
additional effect parameters on the monadic type constructor. These 
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are as follows, along with their types (where for brevity here we 
elide the parameter m for Plus and Unit families and elide Inv): 



(return x 
fx 



m ^ 

Til 

m 3 
(m 



return 
(Xx 

= /): 



(/ x) 
: 9 



■g) 



m (Plus Unit /) a 
m f a 

m (Plus f Unit) a 
rn f a 

m (Plus f (Plus g h)) a 
m (Plus (Plus f g) h) a 



For these equalities to hold, the type-level operations Plus and 
Unit must form a monoid, where Unit is the identity of Plus (for 
the first two laws), and Plus is associative (for the last law). 

Relation to monads All monads are also parametric effect mon- 
ads with a trivial singleton effect, i.e., if we take Unit m = () 
and Plus m () () = (). We show the full construction to embed 
monads into parametric effect monads in Section]?] 

Relation to effect systems Figure |2(a)] recalls the rules of a simple 
type-and-effect system using sets of effect annotations. The corre- 
spondence between type-and-effect systems (hereafter just effect 
systems) and monads was made clear by Wadler and Thiemann, 
who established a syntactic correspondence by annotating monadic 
type constructors with the effect sets of an effect system |24|. This 
is shown for comparison in Figure [2(b)! showing a correspondence 
between (var)-(wm'r), (let)-(bind), and (sub)-(does). 

Wadler and Thiemann established soundness results between an 
effect system and an operational semantics, and conjectured a "co- 
herent semantics" of effects and monads in a denotational style. 
They suggested associating to each effect F a different monad Mf- 
The effect-parameterised monad approach here differs: a type Mf 
of the indexed family may not be a monad itself. The monadic be- 
haviour is "distributed" over the indexed family of types as spec- 
ified by the monoidal structure on effects. Figure [2(c)] shows the 
effect system provided by our parametric effect monad encoding. 

A key feature of effect systems is that the (abs) rule captures all 
effects of the body as latent effects that happen when the function 
is run (this is shown by an effect annotated arrow, e.g., — >•), This is 
also the case in our Haskell embedding: Xx — >• do { ... } is a pure 
function, returning a monadic computation. 

The (sub) rule above provides subeffecting, where effects can 
be overapproximated. Instances of the Subeffect class in Figure [7] 
provide the corresponding operation for parametric effect monads. 

3. Defining type-level sets 

Early examples of effect systems often generated sets of effect 
information, combined via union [101, or in terms of lattices but 
then specialised to sets with union |9|. Sets are appropriate for 
effect annotations when the order of effects is irrelevant (or at 
least difficult to predict, for example, in a lazy language) and when 
effects can be treated idempotently, for example, when it is enough 
to know that a memory cell is read, not how many times it is read. 

Later effect system descriptions separated lattices of effects into 
distinct algebraic structures for sequential composition, alternation, 
and fixed-points 1 17 1. Our encoding of parametric effect monads is 
parameterised by a monoid with a preorder, but sets are an impor- 
tant example used throughout. In this section, we develop a type- 
level notion of sets (that is, sets of types, as a type) with a corre- 
sponding value-level representation. We define set union (for the 
sequential composition of effect information) and the calculation 
of subsets- providing the monoid and preorder structure on effects. 

Defining type-level sets would be easier in a dependently-typed 
language, but perhaps the most interesting (and practically useful) 
thing about this paper is that we can embed effect systems in a 
language without resorting to a fully dependently-typed system. 
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(a) Gifford-Lucassen-style effect system 1 9 1 
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(b) The core effectful rules for Wadler and Thiemann's Monad language for 
unifying effect systems with a monadic metalanguage 1241 . 
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(c) The type-embedded effect system provided in this paper by the paramet- 
ric effect monad definition. 

Figure 2. Comparison of different encodings of effect systems 



Representing sets with lists We encode type-level sets using var- 
ious advanced type system features of GHC. The main effort is in 
preventing duplicate elements and enforcing the irrelevance of the 
storage order for elements. These properties distinguish sets from 
lists, which are much easier to define at the type level and will form 
the basis of our encoding. Type-level functions will be used to re- 
move duplicates and normalise the list (by sorting). 

We start by inductively defining Set as a parameterised GADT: 

data Set (n :: [*]) where 
Empty :: Set '[] 

Ext :: e — > Set s — > Set (e ': s) 

where the parameter has the list kind [*] (the kind of lists of 
types) 1 25 1 . This definition encodes heterogeneously-typed lists, 
with a type-level list representation via type operators of kind: 



and 



CO' 



These provide a compact notation for types. The data constructor 
names Empty and Ext (for extension) remind us that we will treat 
values of this type as sets, rather than lists. 

The first step in using lists to represent sets is to make the order- 
ing irrelevant by (perhaps ironically) fixing an arbitrary ordering on 
elements of the set and normalising by sorting. We use bubble sort 
here as it is straightforward to implement at the type level. 

A single pass of the bubble sort algorithm recurses over a list 
and orders successive pairs of elements as follows: 

type family Pass (I :: [*]) :: [*] where 
Pass'[] =<[] 
Pass '[e] = '[e] 

Pass (e ': f':s) = Mm e f ': (Pass ((Max e f) ': s)) 

type family Mm (a :: k) (b :: k) :: k 
type family Max (a :: k) (b :: k) :: k 

Here, Min and Max are open type families which are given in- 
stances later for specific applications. The definition of Pass here 
uses a closed type family |7|. Closed type families define all of 
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there instances together, i.e., further instances cannot be defined. 
This allows instances to be matched against in order, contrasting 
with open type families where there is no ordering on the instances 
(which may be scattered throughout different modules and com- 
piled separately). Pass is defined as a closed family only because 
we do not need it to be open, not because we require the extra power 
of closed families; a standard open family would suffice here. 

To complete the sorting, Pass is applied n-times for a list of 
length n. The standard optimisation is to stop once the list is sorted, 
but for brevity we take the simple approach, deconstructing the 
input list to build a chain of calls to Pass: 

type family Bubble I I' where 
Bubble l'[] = l 

Bubble I (x ': xs) = Pass (Bubble I xs) 
type Sort I — Bubble I I 

Again, we use a closed type family here, not out of necessity but 
since we do not need an open definition. 

This completes type-level sort. Definitions of the value-level 
counterparts follow exactly the same shape as their types, thus we 
relegate their full definition to Appendix [A] The approach is to 
implement each type-level case as an instances of the classes: 

type Sortable s — Bubbler s s 

class Bubbler s s' where 

bubble :: Set s — > Set s' — ¥ Set (Bubble s s') 

class Passer s where 

pass :: Set s — > Set (Pass s) 

class OrdH e / where 
minH : : e — > f — > Min e f 
maxH lie—)-/—)' Max e f 

This provides the type-specific behaviour of each case of the type- 
level definitions, with room to raise the appropriate type-class con- 
straints for OrdH (heterogeneously typed ordering). 

The remaining idempotence property of sets requires the full 
power of closed type families, using equality on types. We define 
the following type-level function Nub to remove duplicates (named 
after nub for removing duplicates from a list in Data. List): 

type family Nub t where 

Nub<[] ' =«[] 

Nub'[e] ='[e] 

Nub (e ': e ': s) = Nub (e ': s) 

Nub (e ': / ': s) = e ': Nub (/ ': s) 

As mentioned, the closed form of type families allows a number of 
cases to be matched against in lexical order. This allows the type 
equality comparison in the third case which removes a duplicate 
when two adjacent elements have the same type. The pattern of the 
fourth case overlaps the third, but is only tried if the third fails. 

A corresponding value-level nub is defined similarly to bubble 
and pass using a type class with instances for each case of Nub: 

class Nubable t where 
nub :: Set t -> Set (Nub t) 

instance Nubable '[] where 
nub Empty = Empty 

instance Nubable '[e] where 

nub (Ext x Empty) = Ext x Empty 

instance (Nub (e ': / ': s)~(e ': Nub (/ ': s)), 

Nubable (f ': s)) =>■ Nubable (e ': / ': s) where 
nub (Ext e (Ext f s)) = Ext e (nub (Ext f s)) 

In the last case, the equality constraint is required to explain the 
behaviour of Nub. The type and value levels are in one-to-one 



correspondence however we have deliberately omitted the case for 
actually removing items with the same type. This class instance 
will be defined later with application-specific behaviour. 

Putting this all together, type- and value-level conversion of the 
list format to the set format is defined: 

type AsSet s = Nub (Sort s) 

asSet :: (Sortable s, Nubable (Sort s)) => 

Set s -> Set (AsSet s) 
asSet x = nub (bsort x) 

We also define a useful predicate for later definitions which asks 
whether a type is in the set representation format: 

type IsSet s — (s~Nub (Sort s)) :: Constraint 

This uses the constraint kinds extension [3, 20] where the kind 
signature explains that this "type" definition is a unary constraint. 

Now that we have the representation sorted, we define opera- 
tions for taking the union and calculating subsets. 

Union Set union is defined using our existing infrastructure and 
the concatenation of the underlying lists: 

type Union s t — AsSet (Append s t) 

Append concatenates the two list representations (acting like a 
disjoint union of sets) and AsSet normalises the result into the set 
form. Append is defined in the usual way as a type family: 

type family Append (s :: [*]) (t :: [*]) :: [*] where 
Append '[] t = t 

Append (x ': xs) ys = x ': (Append xs ys) 

The value-level version is identical (mutatis mutandis): 

append :: Set s — > Set t — > Set (Append s t) 
append Empty x = x 

append (Ext e xs) ys — Ext e (append xs ys) 

This twin definition, and the previous definition for Nub/nub, 
exposes a weakness of Haskell: we have to write both the value and 
type level, even though they are essentially identical. Languages 
that implement richer dependent-type theories tend to avoid this 
problem but, for the moment, this is the state of play in Haskell. 
Given all of the above, union of value sets is then: 

type Unionable s t — (Sortable (Append s t), 

Nubable (Sort (Append s t))) 
union :: (Unionable s t) =>■ Set s — > Set t — > Set (Union s t) 
union s t = nub (bsort (append si)) 

with the binary predicate Unionable hiding the underlying type 
class constraints associated with sorting and removing duplicates. 

Subsets A notion of subeffecting is useful for combining effect 
information arising from non-linear control flow (for example, to 
implement conditionals). We recursively define a binary predicate 
Sub where Sub s t means s C t. This type class has a single 
method that calculates the value representation of the subset: 

class Subset s t where 
subset :: Set t — > Set s 

instance Subset '[] t where 
subset xs = Empty 

instance Subset s t => Subset (x ': s) (x ': t) where 

subset (Ext x xs) — Ext x (subset xs) 

instance Subset s t =>■ Subset s (x ': t) where 

subset (Ext _ xs) = subset xs 

Thus, in the first instance: empty sets are subsets of all sets; in 
the second: ({a:} US)C ({x} U T) if S C T; and in the third, 
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S C ({a;}UT) if S C T. Note that we have used a multi-parameter 
type class here since the value-level behaviour depends on both the 
source and target types. 

Set union and subset operations will be used in the next three 
sections, where additional set operations will appear as necessary. 

4. Writer effects 

Our first example effect system will capture write effects, related 
to the writer monad. The classic writer monad provides a write- 
only cumulative state, useful for producing a log (or trace) along 
with a computation. The data type is essentially that of a product. 
In Haskell, this monad is defined: 

data Writer w a = Writer {run Writer :: (a,w)} 

instance Monoid w =>■ Monad ( Writer w) where 
return a = Writer (a, mempty) 

( Writer (a, w)) ^= k = let (6, w') = runWriter (k a) 
in Writer (b, w 'mappend' w') 

where mempty:: Monoid w =>■ w and mappend :: Monoid w =>■ 
w — > w — >• w are respectively the unit element and the binary 
operation of a monoid on w. Thus, a pure computation writes the 
unit element of the monoid and composes write state using 

the binary operation of the monoid. 

Using a parametric effect monad, we can define a more flexible 
version of the writer monad that allows multiple writes to be eas- 
ily combined and extended (without the need for tuples or monad 
transformers), using an effect system for write effects. This ap- 
proach allows us to define programs like the following: 

prog :: Writer '["x" :— > Int. "y" :— > String] () 
prog = do put ( Var :: ( Var "x")) 42 

put (Var:: (Var "y")) "hello" 

put (Var :: (Var "x")) 58 

where "x" and "y" are type level symbols and Writer is parame- 
terised by a set of variable-type mappings. Running this computa- 
tion produces ((), {(Var, 100), (Var, "hello")}). 

We use our type-level sets representation coupled with type- 
level symbols to provide variables, where the constructor :— > de- 
scribes a pair of a variable and its written type. The Writer data 
type and its accompanying parametric effect monad are defined: 

data Writer w a = Writer {runWriter :: (a, Set w)} 

instance Effect Writer where 

type Inv Writer s t = (IsSet s, IsSet t, Unionable s i) 

type Unit Writer = '[] 

type Plus Writer s t = Union s t 

return x — Writer (x, Empty) 

(Writer (a, w)) 3= k = let Writer (b, w') — k a 

in Writer (b, w l union' w') 

Thus, return has the empty set effect, and composes writer 

states by taking the union, with the Union effect annotation. The 
IsSet predicates ensure the effect indices are in the set format. 

The put operation is then defined as follows, introducing an 
effect with a variable-type mapping: 

put :: Var v — > t — > Writer '[u :— > t] () 
put v x = Writer ((), Ext v x Empty) 

The mapping operator :— > and Var type are defined: 

data (v :: Symbol) :— > (t ::*) = ( Var v) :— > t 
data Var (v :: Symbol) = Var 

Members of the kind of symbols Symbol are type-level strings, 
provided by the data kinds extension. 



Recall that we did not define the nub operation on sets fully; the 
case for removing duplicates at the value level was not included in 
the definition of Section[3] We define this here by combining values 
of the same variable using the mappend operation of a monoid: 

instance (Monoid a, Nubable ((v :— > a) ': s)) => 

Nubable ((v :— > a) ': (v :— > a) ': s) where 
nub (Ext (_ :— > a) (Ext (v :— > b) s)) = 

nub (Ext (v :— > (a 'mappend 1 b)) s) 

We finally implement the type-level ordering of mappings v :— > t 
by providing instances for Min and Max: 

type instance Mm (v :— s> a) (w :— > b) = 

(Select v w v w) :— ¥ (Select v w a b) 
type instance Max (v :— > a) (w :— > b) — 

(Select v w w v) :— > (Select v w b a) 

type Select a b p q= Choose (CmpSymbol a b) p q 

type family Choose (o :: Ordering) p q where 
Choose LT p q — p 
Choose EQ p q = p 
Choose GT p q = q 

where CmpSymbol :: Symbol — > Symbol — > Ordering from the 
base library compares symbols, returning a type of kind Ordering 
upon which Choose matches. The type function Select selects 
its third or fourth parameter based on the variables passed as its 
first two parameters; Select returns its third parameter if the first 
parameter is less than the second, otherwise it returns its fourth. 
The corresponding value level is a straightforward (and annoying!) 
transcription of the above, shown in Appendix|B]for reference. 

Examples and polymorphism The following gives a simple ex- 
ample (using an additive monoid on Int): 

varX = Var :: ( Var "x") 
varY — Var :: ( Var "y") 

test — do put varX (42 :: Int) 
put varY "hello" 
put varX (58 :: Int) 
put varY " world" 

The effects are easily inferred (shown here by querying GHCi): 

*Main> :t test 

test :: Writer ' ["x" : -> Int, "y" : -> [Char]] () 

and the code executes as expected: 

*Main> runWriter (test 1) 

(0,(x, 100), (y, "hello world")) 

Explicit type signatures were used on assignments to "x" otherwise 
our implementation cannot unify the two writes to "x". If we want 
"x" to be polymorphic we must use a scoped type variable with a 
type signature fixing the type of each put to x. For example: 

test' (n :: a) = do put varX (42 :: a) 
put varY "hello" 
put varX (n :: a) 

for which Haskell can infer the expected polymorphic effect type: 

*Main> :t test' 

test' :: (Monoid a, Num a) => 

a -> Writer ' ["x" :-> a, "y" : -> [Char]] () 

While it is cumbersome to have to add explicit type signatures for 
the polymorphism here, the overhead is not vast and the type sys- 
tem can still infer the effect type for us. We can also be entirely 
polymorphic in an effect, and in a higher-order setting. For exam- 
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pie, the following function takes an effectful function as a parame- 
ter and applies it, along with some of its own write effects: 

test2 :: (IsSet /, Unionable / '["y" :->• String]) 
=> (Int -> Writer f t) 
-> WViier {Union f '["y" String]) () 

iesig / = do {/ 3; put varY "world. " } 

Thus, test2 takes an effectful /, calls it with 3, and then writes 
to "y". The resulting effect is thus the union of f's effects and 
'["y" :— ^ String]. To test, runWriter (test2 test') returns the 
expected values ((), { (x, 45), (y, "hello world. ")}). 

While the type of test2 can be inferred (if we give a signature 
on 3, e.g., 3 :: Int), we include an explicit type signature here as 
GHC has a habit of expanding type synonym definitions, making 
the inferred type a bit inscrutable. 

Subeffecting Since sets appear in a positive position in our 
Writer data type, subeffecting overapproximates what is written, 
requiring a superset operation for writer effects. At the value level, 
we fill these additional writer cells with unit of the corresponding 
monoid (mempty), thus completing the use of monoids in this ex- 
ample (rather than just semigroups). We define a binary predicate 
Superset with a superset method: 

class Superset s t where superset :: Set s — > Set t 
instance Superset ' [ ] ' [ ] where superset _ = Empty 
instance (Monoid a, Superset '[] s) => 

Superset '[]((«:—► a) ': s) where 
superset _ = Ext ( Var mempty) (superset Empty) 

instance Superset si=> 

Superset ((v :— > a) ': s) ((v :— > a) ': t) where 
superset (Ext x xs) — Ext x (superset xs) 

The subeffecting operation for Writer is then: 

instance Superset s t => Subeffect Writer s t where 

sub ( Writer (a, w)) = Writer (a, (superset w) :: (Set t)) 

To illustrate, we apply sub to our earlier example: 

tests :: Writer l ["x" Int, "y" String, "z" Int] () 
tests = sub (test2 test') 

which evaluates to the following showing the 0 value given to "z" 
coming from the additive monoid for Int: 

*Main> runWriter test3 

(0,(x, 45), (y, "hello world."), (z, 0)) 

Using plain lists A simpler, but less useful version of writer ef- 
fects uses just type-level lists, rather than sets. This provides a 
write-once writer where values can be written but with no accu- 
mulating behaviour. We elide this example here as it is less useful, 
but it can be found in Control . Effect .WriteOnceWriter. 

4.1 Update effects 

An alternate form of writer effect provides an updateable mem- 
ory cell, without any accumulating behaviour. This corresponds 
to the usual writer monad with the monoid over Maybe: writing 
a value wrapped by the Just constructor updates the cell, writ- 
ing Nothing leaves the cell unmodified. With a parametric effect 
monad we can treat the type of the cell as an effect annotation, 
providing a heterogeneously-typed update monad. The standard 
monadic definition must have the same type throughout the com- 
putation. Thus, this effect system is more about generalising the 
power of the monad than program analysis per se. 

This parametric effect monad is defined by lifting the Maybe- 
monoid to types. We define a GADT parameterised by Maybe 
promoted to a kind: 



data Eff (w :: Maybe *) where 
Put :: a -> Eff (Just a) 
NoPut :: Eff Nothing 

The effect-parameterised version of the update monad is then: 

data Update w a — U {runUpdate :: (a, Eff w)} 

instance Effect Update where 
type Unit Update = Nothing 

type Plus Update s Nothing = s 
type Plus Update s (Just t) = Just t 

return x — U (x, NoPut) 

(U (a, w)) 3= k = U (update w (runUpdate $ k a)) 

update :: Eff s -> (b, Eff t) -> (b, Eff (Plus Update s t)) 
update w (b, NoPut) — (b, w) 
update _ (b, Put w") = (b, Put w") 
put :: a — > Update (Just a) () 
put x — U ((), Put x) 

where update combines value- and type-level Maybe monoid be- 
haviour. Note that we don't have to use the GADT approach. We 
could equivalently define two data types Put and NoPut and im- 
plement the type-dependent behaviour of update using a type class. 

The effect-parameterised writer monad therefore provides a 
heterogeneously-typed memory cell, where the final type of the 
state for a computation is that of the last write, e.g. 

foo :: Update (Just String) () 
foo = do {put 42; put "hello"} 

This parametric effect monad is a little baroque, but it serves to 
demonstrate the heterogeneous behaviour possible with parametric 
effect monads and gives an example effect system that is not based 
on sets (of which there are more examples later). 

5. Reader effects 

The classic reader monad provides a read-only value (or parame- 
ter) that is available throughout a computation. The data type of the 
reader monad is a function from the read-only state to a value: 

data Reader r a — Reader {runReader :: r — > a} 

Similarly to the previous section, we can generalise this monad 
to a parametric effect monad providing an effect system for read 
effects and allowing multiple different reader values, solving the 
composition problem for multiple reader monads. The generalised 
type and parametric effect monad instance are defined: 

data Reader s a = R { runReader :: Set s a} 

instance Effect Reader where 
type Inv Reader s t = (IsSet s, IsSet t, 

Split s t ( Union s t)) 

type Unit Reader — '[] 

type Plus Reader s t — Union s t 

return x = R (XEmpty — > x) 

(R e) >= k = R (Xst -¥ let (s, t) = split st 

in (runReader % k (e s)) t) 

A pure computation therefore reads nothing, taking the empty set 
as an argument. For the composition of effectful computations, we 
define a computation that takes in a set st :: Set ( Union s t) and 
then splits it into two parts s :: Set s and t :: Set t which are passed 
to the subcomputations e :: Set s — > a and k (e s) : Set t —> b. 

Although set union is not an injective operation (i.e., not invert- 
ible), the split operation here provides the inverse of Union s t 
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since s and t are known, provided by the types of the two subcom- 
putations. We define split via a type class that is parameterised by 
its parameter set and return sets: 

class Split s t st where split :: Set st — > (Set s, Set t) 

instance Split '[] '[] '[] where 

split Empty — (Empty, Empty) 

instance Split s t st =>■ Split (e ': s) (e ': t) (e ': st) where 
split (Ext x st) — let (s, t) = split st in (Ext x s, Ext x t) 

instance Split s t st => Split (x ': s) t (x ': st) where 
split (Ext x st) — let (s, t) = split st in (Ext x s, t) 

instance Split s t st =>■ Split s (x ': t) (x ': st) where 
sp/it (U:rf x st) — let (s, t) = sp/it st in (s, Ext x t) 

The first instance provides the base case. The second provides the 
case when an element of a Union f g appears in both / and g. 
The third and fourth instances provide the cases when an element 
of Union f g is only in / or only in g. 

The constraint Spht s t (Union s t) in the Effect instance 
enforces that Split is the inverse of Union. 

Once we have the above parametric effect monad, the usual ask 
operation takes a variable as a parameter and produces a computa- 
tion with a singleton effect for that variable: 

ask :: Var v — > Reader l [v :— > t] t 

ask Var = R (X(Ext ( Var :— > x) Empty) — > x) 

The following gives an example program, whose type and effects 
are easily inferred by GHC, so we do not give a type signature here: 

foo — do x <— ask (Var :: (Var "x")) 
xs ask (Var :: (Var "xs")) 
x' «— ask (Var :: (Var "x")) 
return (x : x : xs) 

initl = £to ( Far 1) (.Erf ( Var [2, 3]) Empty) 
runFoo — runReader foo initl 

The inferred type is /oo :: Reader '["x" a, "xs" :-> [a]] [a] 
and runFoo evaluates to [1, 1, 2, 3]. 

Note that we have not had to add a case for the Nubable type 
class with the nub method to removing duplicates in sets. This 
is because Reader does not use union (sets appear in a negative 
position, to the left of the function arrow). Instead, the idempotent 
behaviour is encoded by the definition of split) 'Split. 

Sub effecting Since sets appear in negative positions, we can use 
the subset function defined earlier for subeffecting: 

instance Subset s t => Subeffect Reader s t where 
sub (R e) = R (Xst — > let s — subset st in e s) 

The following overapproximates the effects of the above example: 

bar :: (Subset'["x" Int, "xs" [Int]] t) => Reader t [Int] 
bar = sub foo 

This can be run by passing _L into the additional slot in the incom- 
ing reader set with initial reader state: 

init.2 :: Set'["x" Int, "xs" [Int], "z" a] 
in&8 = £rf ( Var 1) (Est ( Var [2, 3]) 
(Est (Vbr _L) Empty)) 

where runReader bar init2 evaluates to [1, 1, 2, 3]. The explicit 
signature on initB is required for the subeffecting function to be 
correctly resolved. 

This effect system resembles the implicit parameters extension 
of Haskell 1 14 1, providing most of the same functionality. However, 
some additional structure is need to fully replicate the implicit 



parameter behaviour. This is discussed in Section [8] where we 
briefly discuss the dual notion of coeffect systems. 

6. State effects 

The earliest effect systems were designed specifically to track side- 
effects relating to state, with sets of triples marking read, write, 
and update effects on typed locations. We combine the approaches 
thus far for reader and writer effects to define a parametric state 
effect monad with state effect system. As before, we will use sets 
for effects, but this time with additional type-level information 
for distinguishing between reads, writes, and updates (read/write), 
given by the Eff type: 

data Eff = R\ W | RW 
data Effect (s :: Eff) = Eff 

where the Effect type uses Eff as a data kind and provides a data 
constructor that acts as a proxy for Eff . These effects markers are 
associated with types, describing the effect performed on a value of 
a particular type, with the constructor: 

data (:!) (a :: *) (s :: Eff) = a :! (Effect s) 

Effect annotations will be sets of mappings of the form (v t :!/) 
meaning variable v has type t and effect action / (drawn from Eff ). 

The parametric effect monad data type State is analogous to 
usual definition of state s — > (a, s): 

data State s a — State 

{runState :: Set (Reads s) — > (a, Set (Writes s))} 

where Reads and Writes refine the set of effects into the read and 
write effects respectively. Read is defined: 

type family Reads t where 
Reads '[] = '[] 

Reads ((v :— > a :! R) ': s) = (v :— > a :! R) ': (Reads s) 
Reads ((v :— > a :! RW) ': s) = (v :— > a :! R) ': (Reads s) 
Reads ((v :— > a :! W) ': s) = Reads s 

thus read-write effects RW are turned into read effects, and all 
write effects are ignored. The Writes operation (not shown here) 
removes R actions and turns RW actions into W actions. 

Previously, set union combined effect sets, but now we need 
some additional behaviour in the case where both sets contain ef- 
fects on a variable v but with different effect actions. For example, 
we require the behaviour that: 

Union '[v t :! R] '[v t :! W] = '[v t :! RW] 

i.e., if one computation reads v and the other writes v the overall 
effect is a read-write effect (possible update). We thus redefine the 
previous Nub definition: 

type family Nub t where 

Nub'[] ' =<[] 

Nub l [e] ='[e] 

Nub (e ': e ': s) — Nub (e ': s) 

Nub ((v :— > a :! /) ': (v :— > a :! g) ': s) = 

Nub ((v a :! RW) ': s) 
Nub (e ': / ': s) = e ': Nub (f ': s) 

Again, closed type families are used to match against types in the 
given order. The definition is the same as before in Section[3] apart 
from the third case which is new: if there are two different effects 
/ and g on variable v then these are combined into one effect 
annotation with action RW. The value level is straightforward and 
analogous to the type-level (see Control . Ef feet . State) and is 
similar to the previous definition in Section|3] The union of two sets 
is defined as before, using sorting and the above version of Nub. To 
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distinguish this union from the previous (which is an actual union), 
we define type UnionS s t = Nub (Sort (Append s t)). 

A final operation is required to sequentially compose write ef- 
fects of one computation with read effects of another. This amounts 
to a kind of intersection of two sets, between a set of write effects 
and a set of read w n r where at the type level this equals r, but 
at the value level any reads in r that coincide with writes in w are 
replaced by the written values. We define this operation by first ap- 
pending the two sets, sorting them, then filtering with intersectR: 

type IntersectR s t — (Sortable (Append s t), 
Update (Append s t) t) 

intersectR :: (Writes s~s, Reads t^t, IntersectR s t) 

=> Set s -> Set t-i- Sett 
intersectR s t = update (bsort (append s t)) 

The constraints here restrict us to just read effects in s and write 
effects in t. The update function replaces any reader values with 
written values (if available). This is defined by the Update class: 

class Update s t where update :: Set s — > Set t 

instance Update xs " [ ] where update _ = Empty 

instance Update 1 [e] l [e] where update s — s 

instance Update ((v :— ► a :! R) ': as) as' => 

Update ((v :—¥ a :! W) ': (v :—¥ b :! R) ': as) as' where 
update (Ext (v :— > (a :! _)) (Ext _ xs)) = 

update (Ext (v (a :! (Eff :: (Effect R)))) xs) 

instance Update ((u :— » b :! s) ': as) as' =>■ 

Update ((v :— > a :! W) ': (u b :! s) ': as) as' where 
update (Ext _ (Ext e xs)) = update (Ext e xs) 

instance Update ((u :— > b :! s) ': as) as' =>■ 
Update ((v :— > a :! R) ': (u :— > 6 :! s) ': as) 

((d :— > a :! _R) ': as') where 
update (Ext e (Ext e' xs)) = Ext e (update (Ext e' xs) 

The first two instances provide the base cases. The third instance 
provides the intersection behaviour of replacing a read value with a 
written value. Since sorting is defined on the symbols used for vari- 
ables, the ordering of write effects before read effects is preserved, 
hence we only need consider this case of a write preceding a read. 
The fourth instance ignores a write that has no corresponding read. 
The fifth instance keeps a read that has no overwriting write effect. 
Finally, we can define the full state parametric effect monad: 

instance Effect State where 
type Unit State — '[] 
type Plus State s t = UnionS s t 

return x — State (XEmpty — > (x, Empty)) 

(State e) »= k = State (Xst -> 
let (sR, tR) — spht st 
(a,sW) = e sR 

(b,tW) = (runState (k a)) (sW 'intersectR 1 tR) 
in (b, sW 1 union' tW)) 

Thus, a pure computation has no reads and no writes. When com- 
posing computations, an input state st is split into the reader states 
sR and tR for the two subcomputations. The first computation is 
run with input state sR yielding some writes s W as output state. 
These are then intersected with tR to give the input state to (k a) 
which produces output state tW. This is then unioned with sW to 
get the final output state. 

The definition for Inv is elided (see Control . Effect . State) 
since it is quite long but has no surprises. As before it constrains 
s and t to be in the set format, and includes various type-class 
constraints for Unionable, Split and IntersectR. 



We can now encode the examples of the introduction. For the 
stream processing example, we can define the operations as: 

varC — Var :: (Var "count") 
varS — Var :: (Var "out") 

incC :: State '["count" \-¥ Int :! RW] () 
incC = do {x 4— get varC;put varC (x + 1)} 

writeS :: [a] -> State '["out" [a] :! RW] () 
writeS y = do {x <— get varS;put varS (x -H- y)} 
write :: [a] -> State '["count" Int :! RW, 

"out" :->[«] :\RW] Q 
write x = do { writeS x; incC} 

7. Monads as parametric effect monads 

As explained in the introduction, all monads are parametric effect 
monads with a trivial singleton effect. This allows us to embed 
existing monads into parametric effect monads with a wrapper: 

import qualified Prelude as P 

data Monad m t a where 

Wrap :: P. Monad m m a — > Monad m () a 

unWrap :: Monad m t a — > m a 
unWrap ( Wrap m) = m 

instance (P .Monad m) => Effect (Monad m) where 
type Unit (Monad m) = () 
type Plus (Monad m) s t = () 

return x — Wrap (P. return x) 

(Wrap x) f — Wrap ((P.^=) x (unWrap of)) 

This provides a pathway to entirely replacing the standard Monad 
class of Haskell with Effect. 

8. Implicit parameters and coeffects 

The parametric effect reader monad of Section[5]essentially embeds 
an effect system for implicit parameters into Haskell, an existing 
extension of Haskell 1 14 1 . Implicit parameters provide dynamically 
scoped variables. For example, the following function sums three 
numbers, two of which are passed implicitly (dynamically): 

sum3 :: (Num a, ?s :: a,?y :: a) a — > a 
sumS z — ?x + ?y + z 

where implicit parameters are syntactically introduced by a pre- 
ceding question mark. Any implicit parameters used in an expres- 
sion are represented in the expression's type as constraints (shown 
above). These implicit parameter constraints are a kind of effect 
analysis, similar to that of our reader effect monad. In our approach, 
a similar definition to sumS is: 

sum3 :: (Num a) => a — > Reader '["?x" :— s> a, "?y" :— > a] a 
sum3 z — do x <— ask ( Var : : ( Var " ?x " ) ) 

y ^— ask ( Var :: ( Var "?y")) 

return (x + y + z) 

This is longer than the implicit parameter approach since the do- 
notation is needed to implement effect sequencing and the symbol 
encoding of variables is required, but the essence is the same. 

However, the two approaches have a significant difference. 
Our effect-parameterised reader monad provides fully dynamically 
scoped variables, that is, they are bound only when the computa- 
tion is run. In contrast, implicit parameters allow a mix of dynamic 
and static (lexical) scoping. For example, we can write: 

sum2 :: (Num a, ly :: a) a — > a 

sum2 = let ?x = 42 in Xz — s> 1x + ?y + z 
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where the let binds the lexically scoped ?x inside of the A- 
expression, but ly remains dynamically scoped, as shown by the 
type. Without entering into the internals of Reader we cannot (yet) 
implement the same behaviour with the monadic approach. This il- 
lustrates how the implicit parameters extension is not an instance of 
an effect system or monadic semantics approach, in the traditional 
sense. The main difference is in the treatment of A-abstraction. 

Recall the standard type-and-effect rule for A-abstraction [9|, 
which makes all effects latent. Unifying effect systems with 
monads via parametric effect monads gives the semantics 1121 : 

[T, x : a h e : r, Fj = g : F x a -> M F r 
[r h Xx.e : a — > r, 0J = return(uncurry g) : V — > Mm (a — > M f t) 
where the returned function is pure (as defined by return). 

This contrasts with the abstraction rule for implicit parame- 
ters 1141 . Lewis et al. describe implicit parameter judgments of the 
form C; T h e : r where C augments the usual typing relation with 
a set of constraints. The rule for abstraction is then: 
C;T,v : a h e : r 
{abs) C;Fr-Xv.e:r 

If constraints C are thought of as effect annotations, then we see 
that the A-abstraction is not pure in the sense that the constraints of 
the body e are now the constraints of the A-abstraction (no latent 
effects). When combined with their rule for discharging implicit 
parameters, this allows lexically scoped implicit parameters. 

The semantics of these implicit parameters has been described 
separately in terms of a comonadic semantics for implicit parame- 
ters with a coeffect system 1211 . 

Comonads and coeffects Comonads dualise monads, revealing a 
structure of the following form (taken from Control . Comonad): 

class Comonad c where 
extract :: c a — > a 
extend :: (c a — > 6) — s> c a — > c b 

where extract is the dual of return and extend is the infix dual 
of (>°=). Comonads can be described as capturing input impurity, 
input effects, or context-dependent notions of computation. 

Recently, coeffect systems have been introduced as the comonadic 
analogues of effect systems for analysing resource usage and 
context-dependence in programs [4.8.21]. The semantics of theses 
systems each include a dual to parametric effect monads (in various 
forms), which we call here parametric coeffect comonads (earlier 
called indexed comonads I21I). 

We write coeffect judgments as VI R h e : r, meaning an ex- 
pression e has coeffects (or requirements) R. The key distinguish- 
ing feature between (simple) coeffect systems, shown in 1211 . and 
effect systems is the abstraction rule, which has the form: 

, T, £ : cr?F <g> G h e : r 
(abs) 

T?F h Xx.e :o^r 
for some binary operation <g> on coeffects. Thus, in a coeffect 
system, A-abstraction is not "pure". Instead, reading the rule top- 
down, coeffects of the body are split between the declaration site 
(immediate coeffects) and the call site (latent coeffects); reading 
bottom up, the contexts available at the declaration site and call site 
are merged to give the context of the body. 

In the semantics of coeffect systems, coeffect judgments are 
interpreted as morphisms: \T1F h e : r] : D_p|r] — > [r] where 
Df is a parametric coeffect comonad. The semantics of abstrac- 
tion requires an additional monoidal operation on D of type 
merge : DfA x DqB — > Df®g(A x B), giving the rule: 



Implicit parameters as coeffects A coeffect system (with the 
above abstraction rule) with coeffects as sets of variable-type pairs 
provides the constraints behaviour of implicit parameters [21 1. This 
allows the sum2 example for implicit parameters to be typed, with 
additional syntax for binding implicit parameters: 



(abs 



(let?) 



I F, z : a ? {?x : a,?y : a} h ?x + ly + z : a 
VI {lx : a} h Xz.lx + ?y + z:a 



{?y.a} 



r ? 0 h let? lx = e in (Xz.lx + ?y + z) 



{■!y.a} 

a v a 



Thus, the requirements of the function body are split, with {?x : a} 
becoming an immediate coeffect which is discharged by the let? 
binding, and {ly : a} remaining latent. 

The semantics can be given in terms of a coeffect-parameterised 
product comonad on PfA — A x F, and an operation merge : 
PfA x PgB — > Pfug{A x B) taking the union of the coeffects. 

Reader as a monad or comonad By (un)currying, functions of 
type PfA — > B (e.g., denotations of the coeffect semantics) are 
isomorphic to functions A — > Reader F B of our parametric effect 
reader, i.e., curry :: ((A x F)^B) — > (A->(F-+B)), and vice 
versa by uncurry. Thus, we can structure sequential reader compu- 
tations using either the comonadic or monadic approach. The dif- 
ference is in the treatment of abstraction, as we have seen above 
with merge. However, we can recover the mixed lexical/dynamic 
behaviour of the implicit parameters extension by providing the iso- 
morphic version of merge for the Reader type: 



merge :: (Unionable s t) 
merge k 



[r, x : a?F ® G h e : r 

G 



[T?F h Xx.e : a ^> r] 



g : DF®o(r x a) -» r 
uncurry(g o merge) : D F T (Dgct 



(a — > Reader (Union s t) b) 
— > Reader s (a — > Reader t b) 
R (As — > Xa — > 

R (Xt ~ > runReader (k a) (union s £))) 

This merges the immediate requirements/effects that occur before 
the function is applied and latent requirements/effects for when the 
function is applied, providing requirements Union s t. We see 
here the merging behaviour described above in the coeffect setting, 
where the union of two implicit parameter environments is taken. 

Therefore, merge allows mixed lexical/dynamic scoping of im- 
plicit parameters with Reader. For example, sum2 (which used 
implicit parameters) can now be equivalently expressed as: 

sum2 :: Num a => a — > Reader l ["?y" :— > a] a 
sum2 = let x = (Ext ((Var :: (Var "?x")) 42) Empty) 
in runReader 

(merge (Xz — > do x <— ask (Var :: (Var "?x")) 
y 4- ask (Var :: (Var "?y")) 
return (x + y + z))) x 

Thus, we lexically scope ?x via merge with our original sumS 
definition, leaving only the requirement for ?y. 

We have seen here that Haskell's implicit parameters are a 
kind of coeffect analysis, or an effect analysis with some addi- 
tional structure borrowed from the coeffect/comonadic approach. 
Furthermore, we can use the same approach to encode type 
class constraints, where dictionaries are encoded via the effect- 
parameterised reader monad. The mechanism for implicitly dis- 
charging constraints is not provided here, but our discussion shows 
how parametric effect monads could be used to emulate implicit 
parameters and type-class constraints or to give their semantics. 

9. Program analysis and specification 

In our examples so far, effect indices have had value-level counter- 
parts. For example, the effect set for the reader monad corresponds 
to the set of values being read. However, we may not necessarily 
want, or need, to have a semantic, value-level counterpart to our 
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indices - they may be purely syntactic, used for analysis of pro- 
gramming properties and subsequent specifications for verifying 
program invariants. We show two examples in this section. 

9.1 Data access 

Stencil computations are a common idiom for array programming, 
in which an array is calculated by applying a function at each pos- 
sible index of the array to compute a new cell value, possibly based 
on the neighbouring cells related to the current index. For example, 
convolution operations and the Game of Life are stencil compu- 
tations. One-dimensional stencil computations can be captured by 
functions of type (Array Int a, Int) — > b which describe the local 
behaviour of the stencil, e.g. (ignoring boundary cases here): 

localMean :: (Array Int Float, Int) — > Float 

localMean (x, c) = (x ! (c + 1) + x ! c + x ! (c - 1)) / 3.0 

Promoting this operation to work over all indices of an array is 
provided by the extend operation of a comonad (see the previous 
section) on "cursored arrays" 1181 . Stencil computations can be 
a source of low-level errors, especially when stencils are large, 
performing many indexing operations (as is common). Here we use 
our approach to embed an effect system that tracks the indexing 
operations relative to the cursor index (c above). We define the 
following parameterised, cursored array data type CArray and 
Stencil which captures stencil computations on CArray: 

data CArray (r :: [*]) a = A (Array Int a, Int) 
data Stencil a (r :: [*]) b — S (CArray r a — > b) 

The parameter r has no semantic meaning; we will use effect an- 
notations purely for analysis, and not for any computation. Stencil 
has a parametric effect monad definition with the set union monoid 
over indices and the standard reader definition at the value level. 

instance Effect (Stencil a) where 
type Plus (Stencil a) s t — Union s t 
type Unit (Stencil a) = '[] 

return a = A (\_ — > a) 

{S /) »= k = S (Xa -¥ let (S /') = k(f a) in /' a) 

Our key effectful operation is an operation for relative indexing 
which induces an effect annotation containing the relative index: 

ix :: ( Val (IntT x) Int) =>■ IntT x — ► Stencil a '[IntT x] a 
ix n = S (\(A (a, c)) — > a ! (c + toVal n)) 

with lifting of the kind Nat of natural numbers types to a type of 
integers IntT with a sign kind over Nat: 

data Sign n — Pos n \ Neg n 
data IntT (n :: Sign Nat) = IntT 

Thus, the effect system collects a set of relative indices. We can 
then redefine localMean as: 

localMean :: Stencil Float 

'[IntT (Neg I), IntT (Pos 0),IntT (Pos 1)] Float 

localMean = do a <- ix (IntT :: (IntT (Pos 0))) 
b <- ix (IntT :: (IntT (Pos 1))) 
c <- ix (IntT :: (IntT (Neg 1))) 
return $ (a + b + c) / 3.0 

We observe that, in practice, many stencils have a very regular 
shape to some fixed depth. We can therefore define type-level 
functions for generating stencil specifications of these shapes. For 
example, we define "forward" oriented stencils to depth d as: 

type Forward d = AsSet ((IntT (Pos 0)) ': (Fwd d)) 
type family Fwd d where 



Fwd 0 = '[] 

Fwd d = (IntT (Pos n)) ': (Fwd (d - 1)) 

We can similarly define a backwards definition, and together form 
the common symmetrical stencil pattern: 

type Symm d — 

AsSet ((IntT (Pos 0)) ': (Append (Fwd d) (Bwd d))) 

We can then give localMean the shorter signature: 

localMean :: Stencil Float (Symm 1) Float 

Such signatures provide specifications on stencils from which the 
type system checks whether the stencil function is correctly imple- 
mented, i.e., not missing any indices. The type system will reveal 
to us any omissions. For example, the following buggy definition 
raises a type error since the negative index —1 is missing: 

localMean :: Stencil Float (Symm 1) Float 
localMean = do a ix (Pos Z) 

b «- ix (Pos (S Z)) 

return $ (a + b + b) / 3.0 

In this effect system, effects are ordered by the superset relation 
since we want to recognise when indices are omitted. For exam- 
ple, the effect of localMean is a subset of (Symm 1) as an in- 
dex is missing, therefore localMean's effect is not a subeffect of 
(Symm 1) hence cannot be 'upcast' to it. Thus, effects are overap- 
proximated here by the subset. 

9.2 Counter 

Prior to the work on effect parameterised monads, Danielsson pro- 
posed the Thunk "annotated monad" type |6|, which is parame- 
terised with natural numbers: 0 for return, and addition on the nat- 
ural number parameters for We call this the counter effect 
monad as it can be used for counting aspects of computation, such 
as time bounds in the case of Danielsson, or computation steps. 

data Counter (n :: Nat) a — Counter {forget :: a} 
instance Effect Counter where 

type Unit Counter = 0 

type Plus Counter n m — n + m 

return a — Counter a 

( Counter a) >■= k — Counter . forget $ k a 

tick :: a — > Counter 1 a 
tick x = Counter x 

Thus we can use tick to denote some increment in computation 
steps or time. This effect system can be used to prove complexity 
bounds on our programs. For example, we can prove that the map 
function over a sized vector is linear in its size: 

data Vector (n :: Nat) a where 
Nil :: Vector 0 a 

Cons :: a — > Vector n a — > Vector (n + 1) a 

map :: (a — > Count m b) 

— > Vector n a — > Count (n * m) ( Vector n b) 

map f Nil = return Nil 

map f (Cons x xs) — do x' <— / x 

xs' <— map f xs 
return (Cons x' xs') 

i.e., if we apply a function which takes m steps to a list of n 
elements, then this takes n * m steps. 

The above is a slight simplification of the actual implementation 
(which can be found in Control. Effect .Counter) since type- 
checking operations on type-level natural numbers are currently a 
little under powered: the above does not type check. Instead, if we 
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implement our own inductive definitions of natural numbers, and 
the corresponding + and * operations, then the above type checks, 
and the type system gives us a kind of complexity proof. The only 
difference to the implementation and the above is that we do not 
get the compact natural number syntax in the types. 

10. Category theory definition 

Previous theoretical work introduced parametric effect monads 1121 
1191 (where in 1191 we called them indexed monads). For complete- 
ness we briefly show the formal definition, which shows that para- 
metric effect monads arise as a mapping between a monoid of ef- 
fects (I, a, I) and the monoid of endofunctor composition (which 
models sequential composition). 

Parametric effect monads comprise a functor T : X — > [C,C] 
(i.e., an indexed family of endofunctors) where X is the category 
providing effect annotations. This category X is taken as a strict 
monoidal category (X, a, I), i.e., the operations on effect annota- 
tions are defined as a binary functor • : X x X — > X and an object 
I £ X. The T functor is then a parametric effect monad when it is 
a lax monoidal functor, mapping the strict monoidal structure on X 
to the strict monoid of endofunctor composition ( [C , C] , o , Ic) , 
The operations of the lax monoidal structure are thus: 

>7i : Ic -» Tl I^f.g '■ TF o TG — > T(F a G) 

These lax monoidal operations of T match the shape of the regular 
monad operations. Furthermore, the standard associativity and uni- 
tality conditions of the lax monoidal functor give coherence con- 
ditions to 771 and hf.g which are analogous to the regular monad 
laws, but with added indices, e.g., (J,i,g ° (vi)tg = idra- 

In our definition here, we have used the "extension form" in 
terms of (>°=), as is traditional in Haskell. This is derived from the 
/i (join) operation by x / = (Tf o (j,)x. 

Indexed monads collapse to regular monads when I is a single- 
object monoidal category. Thus, indexed monads generalise mon- 
ads. Note that indexed monads are not indexed families of monads. 
That is, for all indices F £ obj(X) then TF may not be a monad. 

11. Related notions 

Parameterised monads and indexed monads Katsumata used the 
phrase parametric effect monads 1 12], which we adopted here. In 
previous work, we referred to such structures as indexed mon- 
ads 1191 . but we recognise this clashes with other earlier uses of 
the term. Most notably, Haskell already has an "indexed monad" li- 
brary (Control . Monad . Indexed) which provides an interface for 
Atkey's notion of parameterised monad 1 1 1 with operations: 

ireturn :: a — > m i i a 

ibmd :: (a — > m j k b) — > m i j a — > m i k b 

The second and third indices on m can be read like Hoare triples 
(which McBride shows when embedding a similar definition to the 
above in Haskell 1 16]), where mi] a is the triple {i} a {j}, i.e., 
a computation starts with pre-condition i, and computes a value 
of type a providing post-condition j. An alternate view is that m 
here is indexed by the source and target types of morphisms, where 
ireturn is indexed by identities and ibmd exhibits composition. 

We can encode the same approach with our Effect class. Using 
data kinds, we define a kind of morphisms Morph inhabited by 
either the identity Id or a morphism M a b with source a and 
target b. The type, together with the effect monad are defined as: 

data Morph a b = M a b | Id 

newtype T (i :: Morph * *) a = T a 

instance Effect (T :: ((Morph *)) where 

type Unit T = Id 



type Plus T (M a b) (M c d) = M a d 
type Plus T Id (M a b) = M a b 
type Plus T (M a b) Id = M a b 
type Inv T (M a b) (M c d) = c~d 

return a — T a 

( T x) >■= k — let Ty = kx in Ty 

We use the Inv constraint family to force the target type of the left 
morphism to match the source type of the right morphism. Thus, 
Hoare logic-style reasoning can be encoded in our framework, but 
further exploring program logics is a topic for future work. 

Effect handlers Algebraic effects handlers provide a representa- 
tion of effects in terms of effectful operations (rather than an encod- 
ing as with monads) and equations on these (e.g., 1211231 ). This is 
a change of perspective. The monadic approach tends to start with 
the encoding of effects, and later consider the effect-specific opera- 
tions. The algebraic effects approach starts with the operations and 
later considers the encoding as the free structure arising from the 
operations and their equations. This provides a flexible solution to 
the problems of granularity and compositionality for monads. 

Recent work by Kammar, Lindley, and Oury embeds a system of 
effect handlers in Haskell with a DSL [ 1 1 1. The aims are similar to 
ours, but the approach is different. Our approach can be embedded 
in GHC as is, without any additional macros for encoding handlers 
as in the approach of Kammar et al, and it provides rich type 
system information, showing the effects of a program. There are 
also some differences in power. For example, the heterogeneous 
typing of state provided by parametric effect monads is not possible 
with the current handler approach; we could not encode the update 
writer example from Section pTT| However, effect handlers offer 
much greater compositionality, easily allowing different kinds of 
effect to be combined in one system. 

It is our view that parametric effect monads are an intermediate 
approach between using monads and full algebraic effects. 

As mentioned in the introduction, an alternate solution to the 
coarse-granularity of monads is to introduce type classes for each 
effectful operations where type class constraints act as effect an- 
notations (see e.g. 1151 ). A similar approach is taken by Kiselyov 
et al. in their library for extensible effects, which has similarities 
to the effect handlers approach 1 131- By the type-class constraint 
encoding, these effect systems are based on sets with union and or- 
dering by subsets. Our approach allows effect systems based on dif- 
ferent foundations (an arbitrary monoid with a preorder), e.g., the 
number-indexed counter monad (Section [9.2^ , the Maybe-indexed 
update monad (Section [4. \\ , and the ordering of effects by super- 
sets for array indexing effects (Section [9.1^ . 

12. Epilogue 

A whole menagerie of type system features were leveraged in this 
paper to give a shallow embedding of effect systems in Haskell 
types (without macros or custom syntax). The newest closed family 
extension to GHC was key to embedding sets in types, which was 
core to some of our examples. 

While there is a great deal of power in the GHC type system, 
a lot of boilerplate code was required. Frequently, we have made 
almost identical type- and value-level definitions. Languages with 
richer dependent types are able to combine these. Going forward, 
it seems likely, and prudent, that such features will become part of 
Haskell, although care must be taken so that they do not conflict 
with other aspects of the core language. We also advocate for built- 
in type-level sets which would significantly simplify our library. 

Further work is to extend our approach to allow different kinds 
of effect to be combined. One possible approach may be to define 
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a single monad type, parameterised by a set of effect annotations 
whose elements each describe different notions of effect. 
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A. Typed value-level list sorting 

The following gives the value-level definitions of sorting to nor- 
malise lists for the set representation, referenced from Section [3] 
The top-level bubble function is defined by a type class: 

class Bubbler s s' where 

bubble :: Set s — > Set s' — > Set (Bubble s s') 

instance Bubbler s '[] where 
bubble s Empty = s 

instance (Bubbler s t, Passer (Bubble s ()) 
=S> Bubbler s (e ': t) where 
bubble s (Ext _ t) = pass (bubble s t) 

The individual bubble sort pass is defined also by a type class, so 
that the embedded constraints in the 'swapping' case are captured: 

class Passer s where pass :: Set s — > Set (Pass s) 

instance Passer ' [ ] where pass Empty = Empty 

instance Passer '[e] where 

pass (Ext e Empty) = Ext e Empty 

instance (Passer ((Max e f) ': s), OrdH e f) 
=S> Passer (e ': / ': s) where 
pass (Ext e (Ext f s)) = 

Ext (minH e f) (pass (Ext (maxH e f) s)) 

B. Value comparison of variable- value mappings 

Section [4] uses mappings f : — >• i between variables and values. 
Here, we add the value-level comparison operation. Scoped type 
variables are used along with the data type Proxy used for giving 
a value-level proxy to a type of kind k, i.e., Proxy :: Proxy k. 

select :: forall j k a b . (Chooser (CmpSymbol j k)) =>■ 
Var j — > Var k — > a — > b — > Select j k a b 

select x y — choose 

(Proxy :: (Proxy (CmpSymbol j k))) x y 

instance (Chooser (CmpSymbol u v)) =>■ 
OrdH (u :— > a) (v :— > b) where 
minH (u :— > a) (v :— S> b) = Var :— > (select u v a b) 
maxH (u :— > a) (v :— > b) = Var :— > (select u v b a) 

class Chooser (o :: Ordering) where 

choose :: (Proxy o) — > p — > q — > (Choose o p q) 

instance Chooser LT where choose _ p q — p 
instance Chooser EQ where choose _ p q = p 
instance Chooser GT where choose _ p q = q 
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